More and more network service providers are using MPLS in their next generation networks. MPLS is seen as a convergence technology where IP, Frame Relay, ATM can be carried over a single network thereby resulting in savings in operating expenses. Service providers are also using MPLS for providing new services such as L3 VPNs [E. Rosen, Y. Rekhter, “BGP/MPLS VPNs”, Internet Draft, draft-ietf-13vpn-rfc2547bis-01.txt, September 2003, incorporated by reference herein].
One of the main strengths of MPLS as opposed to plain IP is its rich Traffic Management/Traffic Engineering (TM/TE) features [RFC3031: Multiprotocol Label Switching Architecture, IETF Standards Track RFC, January 2001; RFC2702: Requirements for Traffic Engineering over MPLS, IETF Standards Track RFC, September 1999, both of which are incorporated by reference herein]. One of the important MPLS TM features is MPLS DiffServ [RFC3270: MPLS Support of Diff-Serv, IETF Standards Track RFC, May 2002; RFC3564: Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering, IETF Informational RFC, July 2003, both of which are incorporated by reference herein]. Via MPLS, it is possible to set up a tunnel (Label Switched Path—LSP) between two hops that does not follow the traditional IP next-hop routing. MPLS DiffServ allows you to reserve bandwidth for LSPS, to define per-hob-behavior (PHB) treatment for packets using this LSP, etc. [RFC3270: MPLS Support of Diff-Serv, IETF Standards Track RFC, May 2002; RFC2475: An Architecture for Differentiated Services, IETF Informational RFC, December 1998; RFC3260: New Terminology and Clarifications for Diffserv, IETF Informational RFC, April 2002, all of which are incorporated by reference herein.]
There are two types of LSPs in MPLS DiffServ: L-LSP and E-LSP. In the case of L-LSP, the PHB treatment of a packet is inferred from the label value whereas in E-LSP, the treatment is derived from the EXP encoding within the shim header. E-LSPs allows up to 8 different PHBs per LSP (since EXP is a 3-bit wide field [RFC3021: MPLS Label Stack Encoding, IETF Standards Track RFC, January 2001, incorporated by reference herein]). In general, E-LSPs are more widely deployed than L-LSPs.
Various works has been done in the past to support MPLS over ATM. RFC3035 [RFC3035: MPLS using LDP and ATM VC Switching, IETF Standards Track RFC, January 2001, incorporated by reference herein] introduces the concept of Label-Controlled ATM (LC-ATM) where the top label of an LSP is encoded within the Virtual Path/Virtual Circuit Identifier (VPI/VCI) of the ATM cell header. These VPI/VCI values are exchanged by MPLS Label Distribution Protocols like RSVP-TE and LDP [RFC3035: MPLS using LDP and ATM VC Switching, IETF Standards Track RFC, January 2001; RFC3209: Extensions to RSVP for LSP Tunnels, IETF Standards Track RFC, December 2001; RFC3036: LDP Specification, IETF Standards Track RFC, January 2001, all of which are incorporated by reference herein]. RFC3038 [RFC3038: VCID Notification over ATM link for LDP, IETF Standards Track RFC, January 2001, incorporated by reference herein] proposes a technique to associate a unique end-to-end identifier (VCID) with ATM Virtual Circuits (VCs), which can be used to bind MPLS “streams” to existing ATM VCs. In addition to these, Ships-In-Night (SIN) proposes to have both ATM and MPLS control planes working side by side on the same switch without any interaction between them. The work is also underway to have a full MPLS/ATM control plane interworking (e.g., see ATM-MPLS Network Interworking Signaling Specification 1.0, ATM Forum Standard, August 2003, incorporated by reference herein).
In all these approaches, supporting L-LSPs over ATM is straightforward. You usually have one L-LSP mapped into an ATM VC with an appropriate queuing/scheduling treatment to match L-LSPs PHB. RFC3270 [RFC3270: MPLS Support of Diff-Serv, IETF Standards Track RFC, May 2002, incorporated by reference herein] presents protocol extensions to support this.
There is, however, no easy way of supporting E-LSPs over LC-ATM interfaces and is considered unsupported by RFC3270 [RFC3270: MPLS Support of Diff-Serv, IETF Standards Track RFC, May 2002, incorporated by reference herein]. Since EXP bits are stored within the packet that is segmented into cells at the ingress ATM node of the network, transit ATM switches have no idea which PHB to apply to for an incoming cell. To further complicate this situation, most of the existing legacy ATM switches give only one queuing/scheduling treatment to cells belonging to a single VC.
To overcome this problem, the present invention provides a novel solution where E-LSPs can be supported over legacy ATM switches. This solution does not require any new hardware features and can be achieved just by a software upgrade. Only basic ATM functionality support at the hardware such as switching based on standard ATM header and support for standard ATM service classes [ATM Forum Standards.Available: http://www.atmforum.com/standards/approved.html; D. E. McDysan, D. L. Spohn, ATM: Theory and Applications, McGraw-Hill Series on Computer Communications, both of which are incorporated by reference herein] is assumed. This is a cost effective way of supporting E-LSPs over existing legacy ATM networks without any new investment in hardware for network service providers.
The problems in supporting E-LSPs over ATM can be summarized as follows:                1. How to determine PHB treatment of cells in a VC, given that the corresponding EXP encoding is not known, and        2. How to give different PHB treatments (i.e., scheduling, queuing) to cells belonging to same VC.        
To address the first problem, one can think of somehow encoding EXP bits to ATM header. Possible solutions for this approach could be (refer to ATM Forum Standards. Available: http://www.atmforum.com/standards/approved.html; D. E. McDysan, D. L. Spohn, ATM: Theory and Applications, McGraw-Hill Series on Computer Communications, both of which are incorporated by reference herein, for ATM header description and definitions of CLP, PTI, GFC, UNI/NNI, and other ATM related terms):                Using certain PTI values along with CLP bit to carry EXP encoding information, or        Using top two bits of GFC (in UNI interface)/VPI (at NNI interface) along with CLP bit to encode EXP bits, or        Some other cell-header based encoding technique.        
In all these methods, one will be changing the meaning of ATM cell header and restricting the underlying ATM functionality (e.g., certain PTI or GFC/VPI values cannot be used). They all also imply that one will need new ATM switching hardware to support new header formats.
As another alternative solution, one can think of having a SAR (segmentation/reassembly) at each node. Once the cells are reassembled, EXP bits can be recovered from the underlying packet. There could be some ATM switches capable of doing this. However, a vast majority of the existing hardware platforms will not support SAR at every node. Such a method will also increase the jitter/delay unnecessarily within the ATM network.
None of these possible solutions address the second problem. For it, one will need specialized ATM hardware where queuing/scheduling decisions are made at cell level (not at VC level). (This problem can be resolved if SAR is done at every node and the scheduling/queuing is done at packet level, not at cell level. However, this solution still needs specialized hardware and SAR is not typical on ATM switches as mentioned before.) Additionally, this ATM scheduling/queuing hardware should be sophisticated enough to ensure cells from different packets within the same VC are not interleaved (i.e., scheduling of traffic within VCs should be done at individual packet boundaries). (Please notice that this will increase delay/jitter since all of the cells belonging to a packet will be transmitted all at once, in a bursty fashion. Additionally, incoming traffic will be buffered at least until the last cell of a packet is received even when there is no congestion in the network.) There are few existing ATM switches that can provide this level of sophistication.